The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Portions of databases are sometimes distributed to clients and used for a variety of purposes, such as statistical analysis or for marketing purposes. Clients often maintain the data as “read-only” and do not allow modification of the data at the clients. The process starts with a bulk download of data from a database system to a client, also referred to as an “initial download.” For example, a client may request from a database system a copy of a set of database tables that contain data that the client will process and analyze. The database system performs a bulk transfer of the requested database tables to the client and the client begins processing the data.
At some point after the initial download, changes may be made to the source database. This is particularly true in online transaction processing environments, where the frequency of changes may be quite high. At some point, because of the changes made to the source database, the copy of data provided to the client becomes outdated and no longer reflects the source database. It then becomes desirable to update the client's copy of the data, by propagating the changes made to the source database to the client. The process of propagating changes from a source database to a client is often referred to as “synchronization.”
One approach for synchronizing a client with a source database is to “refresh” the client's copy of data by downloading a new copy of data from the database. A benefit of this approach is that it is relatively simplistic. The client specifies the portions of the source database to be downloaded and the data is transferred to the client. The client also does not have to process the received data. One drawback of this approach is that it requires a bulk transfer of data, which may consume a significant amount of computational resources and therefore can be very intrusive to the source database system. Furthermore, the bulk data transfer may include data that was never updated and therefore does not need to be transferred to the client. Hence, in situations where only a relatively small number of data items were updated in the source database, computational resources are wasted transferring data that the client already has.
Another approach for synchronizing a client with a source database involves the source database system providing a copy of the operations performed on the data at the source database system since the initial download to the client. Most database systems maintain a log of operations performed on their databases. In the event of a failure, the database can be reconstructed by starting with an earlier version of the database retrieved from a non-volatile storage and then processing the operations from the log against the earlier version. The benefit of this approach is that only the operations need to be provided to the client, which reduces the amount of data the must be transferred and is less intrusive to the source database system. The drawback of this approach, however, is that the client must process the operations to update its older copy of the data, which can be computationally expensive and time consuming on the client side.
Based upon the foregoing, there is a need for an approach for propagating changes from a database to a client that does not suffer from limitations in prior approaches. There is a particular need for an approach for propagating changes from a database to a client that avoids using bulk transfers to update the client after an initial download. There is a further need for an approach for propagating changes from a database to a client that avoids updating the client's older version of data by processing operations provided by a source database system.